Requirements & Specification Exemplars 1

Specification exemplars are familiar to most software engineering researchers. For instance, many will have encountered the well known library and lift problem statements, and will have seen one or more published specifications. Exemplars may serve several purposes: to drive and communicate individual research advances; to establish research agendas and to compare and contrast alternative approaches; and, ultimately, to lead to advances in software development practices. Because of their prevalence in the literature, exemplars are worth critical study. In this paper we consider the purposes that exemplars may serve, and explore the incompatibilities inherent in trying to serve several of them at once. Researchers should therefore be clear about what successfully handling an exemplar demonstrates. We go on to examine the use of exemplars not only for writing specifications (an end product of requirements engineering), but also for the requirements engineering process itself. In particular, requirements for good requirements exemplars are suggested and ways of obtaining such exemplars are discussed. 1: What are Specification Exemplars? The use of standard exemplars has become a widely accepted tool in specification research. For orientation the reader should have in mind the relatively small number of exemplars appearing frequently in the literature, such as: the lift and the library problems [Marca & Harandi 1987]; the production cell [Lewerentz & Lindner 1995]; the generalized railroad crossing problem [Heitmeyer et al 1993]; the steam boiler control system [Abrial et al 1995]; the patient monitoring system [Stevens et al 1974]; the conference organization system [Olle 1982]; the package router [London & Feather 1986]; the heating system [Marca & Harandi 1987]; the Swiss tournament system [van Diepen & Partsch 1991]; etc. A representative sample can be found in [Icarus 1989]. Such exemplars generally amount to a self-contained, informal description of a problem in some application domain; they are proposed as unique input for the specification process. Exemplars thus define, in the broadest sense, model specification tasks. They are to be considered immutable; the specifier must do the best she can to produce a specification from the problem statement. In this sense, they capture the harshness of reality we cannot expect to change the world to make it more easily specified. Note that exemplars are not quite comparable to the paradigmatic problems which have received attention in computer science, for example Dining Philosophers [Dijkstra 1971]. In such cases the presentation is entertaining but incidental to the problem; the goal of the person formulating the description is to characterize a problematic aspect of computation in as concise and transparent a manner as possible. By contrast, specification exemplars are intended, at some level, to represent the real-world specification task that is, to be case studies. The presentation therefore is at least as important as the underlying set of concerns it embodies. 1. To appear in Automated Software Engineering, Kluwer Pubs., Vol. 4 No. 4, 1997.